@copilot given that more sources might follow in the future, a discovery source is an interface which can implement/use strategies or not. The architecutral choice is where this weighting happens. a source shall always return pairs of Image + score. Each source is responsible to return that and calculate whatever suits for the score. In case of the registry it probably only returns 1 as score for each Image. In the case of prometheus it's based on query and aggregation method. In case of other Metrik backends it might be something else. I think the Design of this is Crucial. Propose 3 architectures that make sense and weigh their pros and cons from Software pattern Perspektive

@copilot given that more sources might follow in the future, a discovery source is an interface which can implement/use strategies or not. The architecutral choice is where this weighting happens. a s...

Here are three architectures for where time-based weighting lives relative to the Source interface:

Architecture A: Strategy injected into Source (current implementation)

Controller → builds ScoreWeighter → injects into PrometheusSource
PrometheusSource.Fetch() applies weighter internally during aggregation
RegistrySource.Fetch() ignores weighting (returns score=1)

Pros:

• Each source owns its full scoring pipeline — single responsibility at source level
• Source can apply weights at the optimal point (per-datapoint before aggregation, not post-hoc)
• No coupling between sources — Registry doesn't need to know about time-weighting
• Backward compatible: nil weighter = no-op

Cons:

• Every new metric-based source must accept and integrate ScoreWeighter independently
• If weighting logic changes, each source implementing it must be updated
• Tight coupling between weighting strategy and source internals (needs access to timestamps)

Architecture B: Decorator/Middleware wrapping Source

Controller → wraps Source in WeightedSource decorator
WeightedSource.Fetch() → delegates to inner Source → post-processes scores

type WeightedSource struct {
    Inner    Source
    Weighter ScoreWeighter
}
func (w *WeightedSource) Fetch(ctx context.Context) ([]ImageResult, error) {
    results, err := w.Inner.Fetch(ctx)
    // apply weighting to scores post-fetch
    for i := range results { results[i].Score = applyWeight(results[i].Score, ...) }
    return results, err
}

Pros:

• Source implementations stay simple — they only compute raw scores
• Open/closed principle: add new weighting behavior without modifying sources
• Composable: stack multiple decorators (weighting, filtering, normalization)

Cons:

• Post-hoc weighting loses per-datapoint granularity — the source already aggregated, you can only re-weight the final score (less accurate for worktime use case)
• ImageResult would need to carry timestamp metadata for the decorator to weight correctly, leaking internal details
• More indirection in the call chain

Architecture C: Scoring as a separate pipeline stage (Source → Scorer → Ranker)

Controller pipeline: Source.Fetch() → Scorer.Apply([]ImageResult) → Ranker.TopN()

type Scorer interface {
    Apply(results []ImageResult, meta []DataPointMeta) []ImageResult
}

Sources return raw results plus optional metadata (e.g., per-datapoint timestamps). A separate Scorer stage applies strategies. The Ranker then sorts and caps.

Pros:

• Clean separation: Source=data, Scorer=weighting, Ranker=selection
• Sources are truly single-purpose (fetch data)
• Scorer is testable independently, strategies are interchangeable
• Scales well: add new scorers without touching sources

Cons:

• Requires sources to expose internal metadata (timestamps, data-point series) — breaks the simple []ImageResult contract
• Over-engineered if most sources (Registry) don't benefit from scoring
• More types/interfaces to maintain; pipeline coordination adds complexity
• Metadata shape differs per source, needs generics or interface{}

Recommendation

Architecture A (current) is the pragmatic choice for now because:

1. Time-weighting fundamentally needs access to per-datapoint timestamps before aggregation — post-hoc approaches (B, C) lose this fidelity
2. Only metric-based sources (Prometheus, future Datadog/Graphite) need weighting; simple sources (Registry) return score=1 and never participate
3. The ScoreWeighter interface is the extension point — new strategies plug in without changing source code

If the project later adds 3+ metric sources that all need the same weighting, it would make sense to extract a shared MetricSource base (a hybrid of A+C) that handles the weighting loop generically, with each backend only providing raw datapoints. But for now that's premature abstraction.

Want me to keep Architecture A as-is, or pivot to one of the alternatives?

@copilot it's fine like it is. Add e2e tests for the current implementation and also seed the prometheus with images that we later do Not want to see in the discovery object

@copilot it's fine like it is. Add e2e tests for the current implementation and also seed the prometheus with images that we later do Not want to see in the discovery object

Added e2e Chainsaw tests in test/e2e/discovery-worktime/ (commit 3rd in branch). Two policies hit the same seeded Prometheus data (aggregation-test namespace with alpine + busybox):

• e2e-worktime-full: window 0–24 weight=1.0 → images discovered with normal positive scores
• e2e-worktime-zero: window 0–24 weight=0.0 → same images discovered but all scores are 0 (nighttime suppression)

The zero-weight policy proves that images seeded in Prometheus (busybox, alpine) are suppressed when the worktime window assigns them zero weight — they still appear in discoveredImages but with score: 0, meaning they rank last and would be dropped by maxImages in a real config with mixed-weight windows.